API-сервер, использующему платформу Gin, реализованы конечные точки для регистрации пользователей,
входа в систему, обработки погодных данных, управления
регионом и его типами, а также прогнозов погоды.
Этот сервер взаимодействует с базой данных MongoDB для
хранения и извлечения данных.

Инструкция к запуску:
    - Запустить docker-compose: sudo docker-compose up --build -d
    - Делать запросы на адресс: 0.0.0.0:8088 пример: curl --location '0.0.0.0:8088/region/weather/2' \
                                                     --header 'Cookie: id=1'

Ниже приведено описание основных компонентов:

RestAPI.go:

Инициализирует веб-сервер с помощью Gin.
Настраивает маршруты для различных ресурсов, таких как учетные записи, регионы, типы регионов, погода и прогнозы погоды.
Использует HTTP-методы POST, GET, PUT и DELETE для взаимодействия с этими ресурсами.
Каждый маршрут сопоставляется с функцией в файле соответствующего ресурса.

weatherForecastAPI.go:

Содержит обработчики API для управления прогнозами погоды.
Включает в себя CRUD-операции и проверку достоверности для публикации и размещения данных прогноза погоды.
Для хранения данных используется MongoDB.
- GET: Проверка авторизации по cookie, валидация параметра forecastId, findOne запрос в бд по regionId
    Шаги функции
    GetWeatherForecastByID
    Аутентификация пользователя:

    Сначала функция пытается получить идентификатор пользователя (loginIdInt) из cookie. Если процесс извлечения или парсинга не удаётся, функция отправляет клиенту HTTP статус 401 (Unauthorized) с сообщением об ошибке и записывает ошибку в лог.
    Проверка существования пользователя:

    Затем функция проверяет существование пользователя в базе данных с помощью вызова GetAccountByID. Если пользователь не найден, функция возвращает статус 401, записывая соответствующую ошибку в лог.
    Извлечение и валидация параметров запроса:

    Функция извлекает параметр forecastId из URL. Этот параметр представляет собой идентификатор прогноза погоды. Если параметр отсутствует или его невозможно преобразовать в число, функция возвращает статус 400 (Bad Request), сообщает об ошибке и записывает её в лог.
    Получение данных о прогнозе погоды:

    С помощью функции GetWeatherForecastByID из модуля работы с базой данных (MongoDB) происходит запрос к базе данных для получения прогноза погоды по идентификатору. Если данные не найдены или возникает другая ошибка, функция отправляет статус 404 (Not Found) с описанием ошибки.
    Проверка корректности данных прогноза:

    Далее функция проверяет корректность данных прогноза с помощью функции checkWeatherCondition. Если данные не проходят проверку, функция возвращает статус 400 с сообщением об ошибке.
    Отправка данных клиенту:

    Если все проверки пройдены успешно, функция отправляет клиенту статус 200 (OK) и данные прогноза погоды в формате JSON.
    Функция
    GetWeatherForecastByID
     (для работы с базой данных):
    Эта функция отвечает за получение данных прогноза погоды из MongoDB:
    Сначала функция подключается к коллекции CollectionWeatherForecast.
    Применяется фильтр по regionId для поиска соответствующей записи.
    Данные декодируются в структуру WeatherForecast.
    Если в процессе возникают ошибки, они регистрируются, и функция возвращает ошибку вместе с пустым объектом WeatherForecast.
- PUT: Проверка авторизации по cookie, валидация regionId и request по структуре weatherForecast.NewPutWeatherForecast, updateOne запрос в бд по параметру regionId
    Этапы функции
    PutWeatherForecast
    Аутентификация пользователя:

    Сначала функция пытается получить идентификатор пользователя из куки. Если процесс извлечения или парсинга не удаётся, функция отправляет клиенту HTTP статус 401 (Unauthorized) с сообщением об ошибке и регистрирует ошибку в журнале (логе).
    Проверка существования пользователя:

    Затем функция проверяет существование пользователя в базе данных с помощью функции GetAccountByID. Если пользователь не найден, функция возвращает статус 401, сообщая о том, что аккаунт не существует, и записывает ошибку в лог.
    Извлечение и валидация параметров запроса:

    Функция извлекает параметр forecastId из URL, который представляет собой идентификатор прогноза погоды. Если параметр отсутствует или его невозможно преобразовать в число, функция возвращает статус 400 (Bad Request), сообщает об ошибке и записывает её в лог.
    Привязка и валидация данных JSON:

    Данные JSON из тела запроса привязываются к структуре NewPutWeatherForecast. Если привязка не удаётся из-за некорректного формата JSON, функция возвращает статус 400 и сообщение о невалидном запросе.
    После успешной привязки данных, функция проверяет их валидность с помощью функции isValidPut. Если данные не проходят валидацию, отправляется статус 400 с соответствующим сообщением.
    Обновление данных в базе данных:

    При успешной валидации данных, функция вызывает метод PutWeatherForecast модуля работы с базой данных для обновления записи. Если при обновлении возникают ошибки, например, о существовании региона с такими же широтой и долготой, функция возвращает соответствующий HTTP статус (409 или 404) с описанием ошибки.
    Получение и отправка обновлённых данных:

    После успешного обновления, функция снова запрашивает обновлённые данные прогноза погоды по идентификатору и отправляет их клиенту с HTTP статусом 200 (OK).
    Функция
    PutWeatherForecast
     для работы с MongoDB:
    Эта функция обновляет данные в коллекции CollectionWeatherForecast:
    Сначала функция подключается к коллекции.
    Создаётся фильтр по _id для поиска соответствующей записи.
    Операция $set используется для обновления данных документа.
    Если при обновлении возникают ошибки, они регистрируются и возвращаются.
- POST: Проверка авторизации по cookie, валидация request по структуре weatherForecast.NewPostWeatherForecast, get запрос в бд для получения последнего id в коллекции, InsertOne запрос в бд с проверкой на не занятость координат структуры NewPostWeatherForecast
    Этапы функции
    PostWeatherByID
    :
    Аутентификация пользователя:

    Сначала функция пытается извлечь идентификатор пользователя из cookie. Если это не удаётся, функция отправляет клиенту ответ со статусом 401 (Unauthorized), указывая на невалидный вход (логин), и записывает ошибку в лог.
    Проверка существования пользователя:

    После получения идентификатора, система проверяет наличие соответствующего пользователя в базе данных. Если пользователь не найден, возвращается ответ 401 с сообщением об отсутствии аккаунта, и событие регистрируется в логе.
    Привязка и валидация данных:

    Далее функция привязывает JSON из тела запроса к структуре NewPostWeatherForecast. Если привязка не удаётся, функция возвращает статус 400 (Bad Request) с сообщением об ошибке.
    После успешной привязки выполняется проверка валидности данных с помощью функции isValidPost. Если данные не проходят проверку, функция возвращает статус 400 с соответствующим сообщением.
    Добавление данных прогноза погоды:

    После валидации данных функция запрашивает последний идентификатор в коллекции прогнозов погоды, чтобы присвоить новому прогнозу ID, увеличенный на единицу.
    Затем создаётся объект WeatherForecast, который заполняется данными из NewPostWeatherForecast и новым ID.
    Если происходит ошибка при получении последнего ID или при добавлении данных в базу, функция возвращает ошибку 500 (Internal Server Error). Если регион с указанным ID не найден, возвращается ошибка 404 (Not Found).
    Функция
    AddWeatherForecast
    :
    Добавление нового прогноза погоды в базу данных:
    Функция начинает с получения доступа к коллекции прогнозов погоды и регионов.
    Проверяется, существует ли регион с указанным ID. Если такой регион не найден, возвращается ошибка "region with this id not found".
    Если регион существует, новый прогноз погоды добавляется в коллекцию weatherForecast. При возникновении ошибок в этом процессе они возвращаются вызывающей стороне.
- DELETE: Проверка авторизации по cookie, валидация параметра forecastId, deleteOne запрос в бд по regionId
    Этапы функции
    DeleteRegionTypeByID
    :
    Аутентификация пользователя:

    Сначала функция пытается получить идентификатор пользователя из cookie. Если процесс извлечения или парсинга не удаётся, функция отправляет клиенту ответ со статусом 401 (Unauthorized), указывая на ошибку в логине, и записывает ошибку в лог.
    Проверка существования пользователя:

    После получения идентификатора, система проверяет наличие соответствующего пользователя в базе данных. Если пользователь не найден, функция возвращает статус 401 с сообщением об отсутствии аккаунта, и событие регистрируется в логе.
    Извлечение и проверка идентификатора типа региона:

    Функция извлекает параметр forecastId из URL (хотя здесь, возможно, ошибка в названии параметра, так как речь идет о типе региона). Если параметр отсутствует или его невозможно преобразовать в число, функция возвращает статус 400 (Bad Request), сообщает об ошибке и записывает её в лог.
    Удаление данных:

    С помощью функции DeleteByIDAndCollection, передавая идентификатор и имя коллекции (CollectionWeatherForecast), происходит удаление документа из базы данных. Если при удалении возникает ошибка или документ не найден, функция возвращает статус 404 (Not Found) с описанием ошибки.
    Функция
    DeleteByIDAndCollection
    :
    Удаление документа из коллекции MongoDB:
    Функция начинает с получения доступа к указанной коллекции в MongoDB.
    Создаётся фильтр по _id для поиска соответствующего документа.
    Выполняется операция DeleteOne, которая удаляет документ, соответствующий фильтру. Если документ для удаления не найден (т.е., DeletedCount равно 0), возвращается ошибка "No document found".
    Если документ успешно удалён, функция регистрирует это событие в логе.
- Вспомогательные функции
    Функция
    isValidPut
    Эта функция проверяет корректность данных для обновления существующего прогноза погоды (NewPutWeatherForecast):

    Проверка формата даты и времени:

    Дата и время (n.DateTime) проверяются на соответствие формату ISO-8601, используя стандарт RFC3339. Это стандартный формат даты и времени для JSON и веб-коммуникаций. Если дата не соответствует этому формату, функция возвращает false.
    Проверка условий погоды:

    Проверяется, что условие погоды (n.WeatherCondition) входит в список разрешенных значений, таких как "CLEAR", "CLOUDY", "RAIN" и т.д. Если указанное условие не находится в этом списке, функция также возвращает false.
    Если оба условия удовлетворены, функция возвращает true, что означает, что данные корректны для обновления.

    Функция
    isValidPost
    Эта функция аналогична isValidPut, но предназначена для проверки данных перед добавлением нового прогноза погоды (NewPostWeatherForecast):

    Проверка формата даты и времени:

    Аналогично isValidPut, проверяется соответствие даты и времени формату ISO-8601.
    Проверка идентификатора региона:

    Проверяется, что идентификатор региона (n.RegionID) является положительным числом. Это гарантирует, что регион существует.
    Проверка условий погоды:

    Также проверяется, что условие погоды входит в список разрешенных значений.
    Если все три условия удовлетворены, возвращается true.

    Функция
    checkWeatherCondition
    Эта функция проверяет, что условие погоды в объекте weatherForecast входит в список известных погодных условий:

    Создается массив известных погодных условий.
    Функция перебирает этот список и проверяет, соответствует ли условие в объекте weatherForecast одному из элементов списка.
    Если найдено соответствие, функция возвращает true. Если после проверки всех условий соответствие не найдено, возвращается false.

weatherAPI.go:

Управляет данными о погоде с помощью функций получения, публикации, добавления и удаления информации о погоде.
Проверяет данные перед вставкой или обновлением в базу данных.
Обрабатывает сеансы пользователей с помощью файлов cookie для аутентификации.
- GET:
    Мне не было ясно кое-что: При запросе на погоду в регионе просят в response вернуть 1 документ, но прогнозов погоды может быть много, в зависимости от времени. НО я решил просто возвращать первый попавшийся документ, который совпадает со всеми условиями, при надобности можно легко найти все прогнозы погоды для этого региона.

    Проверка авторизации по cookie, валидация параметра regionId, запрос в бд по regionId

    Функция начинается с вызова getCollection с config.CollectionWeatherForecast в качестве аргумента. Эта функция отвечает за подключение к базе данных MongoDB и возврат обработчика коллекции. Обработчик коллекции хранится в коллекцииWeatherForecast.
    Если при подключении к коллекции возникает ошибка, ошибка регистрируется, и функция возвращает ноль для среза и ошибки.
    Определите фильтры и контекст:

    Функция определяет фильтр MongoDB bson.D{{'regionId', id}} для запроса прогнозов погоды, соответствующих указанному регионуId.
    Контекст с таймаутом 30 секунд создается с помощью context.WithTimeout. Это гарантирует, что операция базы данных не будет зависать на неопределенный срок и будет ограничена максимальной продолжительностью 30 секунд. Функция отмены отложена, чтобы гарантировать, что она будет вызвана для освобождения ресурсов после завершения операции.
    Запрос прогнозов погоды:

    С помощью обработчика CollectionWeatherForecast выполняется операция поиска с контекстом и фильтром. Это возвращает курсор, указывающий на совпадающие документы.
    Если во время операции поиска возникает ошибка, она регистрируется, и функция возвращает ноль и ошибку.
    Метод курсор.Все используется для декодирования всех найденных документов в срез WeatherForecasts. Если во время этого декодирования возникает ошибка, она возвращается вместе с нулем.
    Получить сбор данных о погоде:

    Как и на первом этапе, функция получает обработчик коллекции для config.CollectionWeather, который содержит фактические данные о погоде.
    Если при подключении к этой коллекции возникает ошибка, она регистрируется и возвращается вместе с нулем.
    Подготовьте фильтр для данных о погоде:

    Функция создает срез WeatherForecastIds для хранения идентификаторов всех найденных прогнозов погоды.
    Он перебирает фрагмент WeatherForecasts и добавляет идентификатор каждого прогноза к WeatherForecastIds.
    Фильтр filterWeather готовится с использованием bson.M{'weatherForecast': bson.M{'$all': WeatherForecastIds}}. Этот фильтр предназначен для получения документов о погоде, в которых поле WeatherForecast содержит любой из идентификаторов в WeatherForecastIds.
    Запрос данных о погоде:

    Операция поиска выполняется снова, но на этот раз для коллекцииWeather с новым фильтром.
    Найденные документы декодируются в результирующий срез структуры Weather.Weather.
    Если во время этой операции возникает ошибка, она регистрируется и возвращается вместе с нулем.
    Результаты возврата:

    Если все операции успешны, функция регистрирует найденные документы и возвращает срез результата, содержащий данные о погоде, а также ноль в случае ошибки.
- PUT:
    Шаги функции
    PutWeather
     в Gin:
    Аутентификация пользователя:

    Сначала функция проверяет, валиден ли идентификатор пользователя, извлеченный из cookie. Если идентификатор не найден или ошибка парсинга, функция отправляет ответ с кодом 401 (Unauthorized), указывая на невалидный вход.
    Проверка существования пользователя:

    После верификации идентификатора делается запрос к базе данных для проверки существования такого пользователя. Если пользователь не найден, возвращается ошибка с кодом 401.
    Получение идентификатора региона:

    Извлекается идентификатор региона из параметров запроса. При ошибке извлечения отправляется ответ с кодом 400 (Bad Request).
    Привязка данных погоды:

    Данные из тела запроса привязываются к структуре NewWeather. Если данные некорректны или не соответствуют ожидаемому формату, отправляется ответ с кодом 400.
    Проверка существования региона:

    Проверяется, существует ли регион с указанным идентификатором. Если регион не найден, отправляется ответ с кодом 404 (Not Found).
    Валидация данных:

    Проверяется валидность данных, включая наличие названия региона и соответствие погодных условий допустимым значениям. При обнаружении невалидных данных отправляется ответ с кодом 400.
    Обновление информации о погоде:

    Подготавливается и отправляется запрос на обновление информации о погоде в базе данных. В случае ошибок во время обновления возвращается ответ с кодом 404.
    Функция
    PutWeather
     для работы с MongoDB:
    Получение коллекции:

    Доступ к соответствующей коллекции MongoDB осуществляется через функцию getCollection.
    Проверка существования записи:

    С помощью FindOne проверяется, существует ли уже запись с таким идентификатором. Если запись не найдена, функция возвращает ошибку.
    Обновление записи:

    Если предыдущие проверки прошли успешно, происходит обновление записи с помощью UpdateOne. В запросе используется оператор $set для обновления полей документа.
    Проверка прогнозов погоды:

    Для каждого идентификатора прогноза погоды в списке проверяется его наличие в базе данных. Если какой-либо из прогнозов не найден, функция возвращает соответствующую ошибку.
- POST: Проверка авторизации по cookie, валидация request по структуре weatherForecast.NewPostWeatherForecast, get запрос в бд для получения последнего id в коллекции, InsertOne запрос в бд с проверкой на не занятость координат структуры NewPostWeatherForecast
    Аутентификация и проверка пользователя:

    Функция начинается с получения идентификатора пользователя (loginIdInt) из файла cookie. Если ему не удается получить или проанализировать этот идентификатор, он регистрирует ошибку и отправляет ответ 401 Unauthorized, указывающий на неверный вход в систему.
    Затем он проверяет, существует ли пользователь в базе данных, вызывая GetAccountByID с полученным идентификатором. Если пользователь не существует, он регистрирует это и возвращает ответ 401.
    Привязка и проверка данных:

    BindJSON используется для привязки входящей полезной нагрузки JSON к структуре newWeather. Если это не удается (например, из-за неправильного формата JSON), он регистрирует ошибку и возвращает ответ 400 Bad Request.
    Затем функция вызывает isValidData для проверки данных newWeather. Вероятно, это проверяет, соответствуют ли данные определенным критериям (например, действительным идентификаторам регионов, погодным условиям и т. д.). Если данные недействительны, он регистрирует ошибку и отправляет ответ 400.
    Операции с базой данных:

    Он извлекает последний идентификатор, использованный в коллекции config.CollectionWeather, для создания нового уникального идентификатора для новой записи погоды. Если эта операция завершается неудачно, она регистрирует ошибку и возвращает 500 Internal Server Error.
    Он извлекает сведения о регионе из базы данных с помощью GetRegionByID на основе RegionId из newWeather. Если регион не найден, возвращается ошибка 409 Conflict.
    После успешного получения региона он устанавливает различные поля в resultWeather как из newWeather, так и из полученных данных региона.
    Наконец, он пытается добавить новые данные о погоде в базу данных, вызывая AddWeather. Если это не удается из-за того, что идентификатор прогноза погоды не соответствует ни одному существующему региону, возвращается ошибка 404 Not Found. При других ошибках возвращается ошибка 500 Internal Server Error.

    Добавить погоду
    Коллекции базы данных:

    Функция извлекает обработчики для коллекций погоды, регионов и WeatherForecast. Если что-то из этого не удается, он регистрирует ошибку и возвращает ее.
    Проверка региона и прогноза погоды:

    Он проверяет, существует ли указанное название региона в базе данных и соответствует ли идентификатор прогноза погоды существующему прогнозу в указанном регионе. Это делается путем запроса коллекций WeatherForecast и Regions.
    Если для предоставленного идентификатора прогноза погоды не найден соответствующий регион, возвращается ошибка, указывающая, что данные о погоде не найдены для данного идентификатора прогноза и региона.
    Вставка данных:

    Если все проверки пройдены, функция вставляет новые данные о погоде в коллекцию погоды. Если это не удается, он регистрируется и возвращает ошибку.
    Обработка ошибок и протоколирование:
- DELETE: Проверка авторизации по cookie, валидация параметра forecastId, deleteOne запрос в бд по regionId
    DeleteWeatherByID
    Аутентификация и проверка пользователя:

    Сначала функция пытается извлечь идентификатор пользователя (loginIdInt) из cookie. Если происходит ошибка, функция регистрирует её, отправляет ответ с HTTP статусом 401 (Unauthorized), сигнализирующий о невалидной аутентификации, и завершает выполнение.
    Затем функция проверяет существование пользователя в базе данных с помощью GetAccountByID. Если пользователь не найден, функция отправляет ответ 401 и записывает ошибку в лог.
    Получение и валидация параметров:

    Функция извлекает параметры weatherId и regionId из URL запроса. Если они не могут быть успешно получены или преобразованы в числовой формат, функция отправляет ответ 400 (Bad Request) и регистрирует ошибку.
    Удаление данных о погоде:

    Вызывается функция DeleteWeatherById, которой передаются weatherId и regionId для удаления соответствующих данных о погоде.
    Если в процессе удаления возникает ошибка, функция отправляет ответ 404 (Not Found) с описанием ошибки и регистрирует её.
    При успешном удалении данных функция отправляет ответ 200 (OK).

    DeleteWeatherById
    Получение коллекции и валидация региона:

    Сначала функция получает информацию о регионе по regionId. Если регион не найден, функция возвращает ошибку.
    Затем функция пытается получить коллекцию weather для доступа к данным о погоде. Если это не удаётся, возвращается ошибка.
    Поиск и удаление данных о погоде:

    Функция создает фильтр для поиска записи о погоде по regionName, полученному из данных региона.
    Затем осуществляется поиск документа в коллекции. Если документ не найден, возвращается ошибка о несуществующем регионе.
    После этого создается фильтр для удаления по _id погоды (weatherId), и производится попытка удалить запись. Если ни один документ не удален, возвращается ошибка о несуществующих данных о погоде.
- SEARCH
    Этапы функции
    SearchWeather
    :
    Получение и проверка параметров запроса:

    Дата и время начала: Параметр startDateTime извлекается из запроса и проверяется на соответствие формату ISO-8601. Если формат неверный, функция возвращает ошибку 400.
    Дата и время окончания: Аналогично начальной дате, endDateTime проверяется и преобразуется.
    Погодные условия: Извлекается параметр weatherCondition и проверяется на наличие в списке допустимых значений. При несоответствии возвращается ошибка 400.
    Идентификатор региона: Параметр regionId проверяется на положительное значение.
    Форма и размер: Параметры form и size используются для пагинации результатов. Они проверяются на корректность и при необходимости возвращается ошибка 400.
    Формирование запроса к базе данных:

    На основе полученных и проверенных параметров формируется запрос к MongoDB для поиска соответствующих записей о погоде. Используются регулярные выражения для дат и условий погоды, а также фильтры для диапазонов дат и региона.
    Выполнение запроса:

    Запрос отправляется в базу данных с учетом пагинации (пропуск определенного количества результатов и ограничение на количество возвращаемых записей).
    Результаты запроса возвращаются клиенту в формате JSON.
    Функция
    GetSearchWeather
    :
    Эта функция вызывается внутри SearchWeather для выполнения запроса к базе данных:

    Получение коллекции:

    Доступ к коллекции погоды в MongoDB осуществляется через функцию getCollection.
    Формирование фильтров:

    Фильтры для MongoDB формируются на основе регулярных выражений и условий, заданных параметрами. Это включает фильтрацию по погодным условиям, датам и региону.
    Опции запроса:

    Опции запроса настраиваются для пагинации результатов.
    Выполнение запроса:

    Запрос выполняется с использованием созданных фильтров и опций. Если возникают ошибки, они обрабатываются и возвращаются вызывающей стороне.
regionTypeAPI.go:

Управляет типами регионов, позволяя пользователям создавать, извлекать, обновлять и удалять типы регионов.
Выполняет проверку правильности введенных данных.

- GET
    Шаги функции
    GetRegionTypeByID
     в Gin:
    Аутентификация пользователя:

    Функция начинает с попытки получить идентификатор пользователя из cookie. Если это не удается или идентификатор неверен, функция отправляет ответ с кодом 401 (Unauthorized), указывая на ошибку аутентификации.
    Проверка существования пользователя:

    Далее, функция проверяет существование учетной записи пользователя в базе данных. Если аккаунт не найден, функция возвращает ответ с кодом 401.
    Извлечение параметра идентификатора типа региона:

    Функция извлекает параметр typeId из URL запроса. Этот параметр содержит идентификатор типа региона, который необходимо получить. При ошибке извлечения отправляется ответ с кодом 400 (Bad Request).
    Запрос к базе данных:

    После успешной аутентификации и получения идентификатора отправляется запрос в базу данных для получения информации о типе региона по его идентификатору.
    Отправка результата или ошибки:

    Если запрос в базу данных успешен, информация о типе региона отправляется клиенту с кодом 200 (OK). В случае ошибки при поиске в базе данных отправляется ответ с кодом 404 (Not Found), сообщая о том, что данные не найдены.
    Функция
    GetRegionTypeByID
     для MongoDB:
    Получение доступа к коллекции:

    Функция получает доступ к коллекции CollectionRegionType в MongoDB, где хранятся данные о типах регионов.
    Поиск документа:

    С использованием переданного идентификатора формируется фильтр для поиска соответствующего документа в базе данных. Запрос выполняется с помощью метода FindOne, который возвращает один документ, удовлетворяющий условию фильтрации.
    Обработка ошибок:

    Если документ не найден или произошла другая ошибка при запросе к базе данных, функция возвращает ошибку и соответствующий пустой объект RegionType.
- POST
    Этапы функции
    PostRegionType
    :
    Аутентификация пользователя:

    Сначала функция пытается получить идентификатор пользователя из cookie. Если процесс извлечения или парсинга не удаётся, функция возвращает ошибку 401 (Unauthorized), указывая на проблемы с аутентификацией.
    Проверка существования пользователя:

    После проверки идентификатора функция делает запрос к базе данных, чтобы убедиться в существовании пользователя. Если пользователь не найден, возвращается ошибка 401.
    Привязка и проверка данных:

    Данные из тела запроса привязываются к структуре NewRegionType. Если привязка не удаётся из-за некорректного формата JSON, возвращается ошибка 400 (Bad Request).
    Проверяется, что поле Type не пустое и не состоит только из пробелов. В противном случае возвращается ошибка 400 с сообщением о невалидных данных.
    Генерация идентификатора и добавление нового типа региона:

    Получен последний идентификатор из коллекции типов регионов, к которому добавляется единица, чтобы создать уникальный ID для новой записи.
    Созданный объект RegionType с новым ID и типом добавляется в базу данных.
    Обработка ошибок при добавлении:

    Если при добавлении возникает ошибка, например, если тип региона уже существует, возвращается ошибка 409 (Conflict) с соответствующим сообщением.
    В случае других ошибок возвращается ошибка 500 (Internal Server Error).
    Отправка успешного ответа:

    При успешном добавлении нового типа региона данные отправляются обратно клиенту с кодом 201 (Created).
    Функция
    AddRegionType
    :
    Эта функция вызывается внутри PostRegionType для добавления нового типа региона в базу данных MongoDB:

    Получение доступа к коллекции:

    Доступ к коллекции CollectionRegionType осуществляется через функцию getCollection.
    Проверка на уникальность типа:

    Производится поиск в базе данных, чтобы убедиться, что тип региона уникален. Если найдена запись с таким же типом, возвращается ошибка, указывающая на существование такого типа.
    Добавление нового типа региона:

    Если тип уникален, новая запись добавляется в коллекцию. При возникновении ошибки во время добавления она обрабатывается и возвращается.
- PUT
    Этапы функции
    PutRegionTypeByID
    :
    Аутентификация пользователя:

    Сначала функция проверяет, валиден ли идентификатор пользователя, извлеченный из cookie. Если происходит ошибка, возвращается статус 401 (Unauthorized), указывая на невалидный логин.
    Проверка существования пользователя:

    Далее, функция делает запрос к базе данных для проверки существования пользователя. Если аккаунт не найден, возвращается ошибка с кодом 401.
    Получение идентификатора типа региона:

    Извлекается параметр typeId из URL запроса. При ошибке извлечения возвращается ошибка с кодом 400 (Bad Request).
    Привязка и проверка данных:

    Данные из тела запроса привязываются к структуре NewRegionType. Если привязка не удаётся или данные невалидны (например, поле Type пустое), возвращается ошибка 400.
    Обновление данных в базе:

    После успешной валидации данных выполняется запрос к базе данных для обновления типа региона. Если при обновлении возникает ошибка, например, если тип региона уже существует, возвращается ошибка 409 (Conflict). В противном случае, если тип региона не найден, возвращается ошибка 404 (Not Found).
    Возврат обновленной информации:

    После успешного обновления, функция извлекает обновленную информацию о типе региона и отправляет её клиенту с кодом 200 (OK).
    Функция
    PutRegionType
    :
    Обновление записи в MongoDB:
    Получен доступ к коллекции CollectionRegionType.
    Проверяется существование записи с указанным идентификатором (id). Если запись не найдена, возвращается ошибка.
    Дополнительно проверяется уникальность поля Type. Если найдена другая запись с таким же типом, но другим идентификатором, возвращается ошибка о том, что такой тип уже существует.
    Если все проверки пройдены успешно, информация о типе региона обновляется в базе данных.
- DELETE
    Этапы функции
    DeleteRegionTypeByID
    :
    Аутентификация пользователя:

    Функция начинает с попытки получить идентификатор пользователя из cookie. Если извлечь идентификатор не удаётся, возвращается ошибка 401 (Unauthorized), указывающая на проблемы с аутентификацией.
    Проверка наличия аккаунта пользователя:

    Делается запрос к базе данных для проверки существования аккаунта по полученному идентификатору. Если аккаунт не найден, функция возвращает ошибку 401.
    Получение идентификатора типа региона:

    Из параметров запроса извлекается идентификатор типа региона (typeId). При ошибке извлечения возвращается ошибка 400 (Bad Request).
    Удаление типа региона:

    Выполняется попытка удалить тип региона. Если тип региона используется как родительский для других регионов, возвращается ошибка 400, указывающая на то, что удаление невозможно из-за наличия зависимостей.
    Если при удалении возникают другие ошибки, возвращается ошибка 404 (Not Found).
    Успешное удаление:

    Если удаление прошло успешно, функция отправляет ответ с кодом 200 (OK), подтверждая успешное удаление типа региона.
    Вспомогательная функция
    DeleteRegionTypeByID
     для MongoDB:
    Проверка на зависимости:

    Сначала функция проверяет, используется ли удаляемый тип региона как родительский для других регионов в коллекции Regions. Это делается путём поиска регионов с соответствующим regionType.
    Если найдены регионы, использующие этот тип, возвращается ошибка, указывающая на наличие зависимостей.
    Удаление типа региона:

    Если зависимости отсутствуют, функция продолжает с удалением типа региона из коллекции RegionType с использованием вспомогательной функции DeleteByIDAndCollection.

regionAPI.go
- GET
    Этапы функции
    GetRegionByID
     в Gin:
    Аутентификация пользователя:

    Сначала проверяется, можно ли извлечь идентификатор пользователя из cookie. Если это не удаётся, отправляется ответ с кодом 401 (Unauthorized), что указывает на проблемы с аутентификацией пользователя.
    Проверка существования аккаунта пользователя:

    Далее, делается запрос к базе данных для проверки существует ли аккаунт пользователя с полученным идентификатором. Если аккаунт не найден, функция возвращает ответ с кодом 401, сообщая о том, что аккаунт пользователя не существует.
    Получение идентификатора региона:

    Из параметров запроса извлекается идентификатор региона (regionId). Если происходит ошибка при этом шаге, возвращается ответ с кодом 400 (Bad Request), сообщающий об ошибке в запросе.
    Запрос к базе данных:

    После проверки аутентификации и получения идентификатора региона, делается запрос к базе данных для получения информации о регионе. В случае, если информация о регионе не найдена или произошла другая ошибка, функция возвращает ответ с кодом 404 (Not Found), указывая на отсутствие данных.
    Отправка данных:

    Если данные о регионе успешно получены, они отправляются клиенту с кодом 200 (OK) в формате JSON.
    Функция
    GetRegionByID
     для работы с MongoDB:
    Получение доступа к коллекции:

    Доступ к коллекции CollectionRegions осуществляется через функцию getCollection. В случае ошибки при получении доступа к коллекции, функция возвращает ошибку.
    Поиск документа:

    Используется фильтр по идентификатору (_id) для поиска соответствующего документа в базе данных. Запрос выполняется методом FindOne, который возвращает один документ.
    Обработка ошибок:

    Если документ не найден или произошла другая ошибка при выполнении запроса, возвращается соответствующая ошибка. В случае успешного нахождения документа, информация о регионе возвращается вызывающей стороне.
- POST
    Этапы функции
    PostRegion
    :
    Аутентификация пользователя:

    Сначала функция проверяет наличие и валидность идентификатора пользователя, извлеченного из cookie. Если процесс извлечения или проверки не удаётся, отправляется ответ с кодом 401 (Unauthorized), указывающий на проблемы с аутентификацией.
    Проверка существования аккаунта пользователя:

    Далее делается запрос к базе данных для проверки существования аккаунта пользователя по полученному идентификатору. Если аккаунт не найден, возвращается ошибка с кодом 401.
    Привязка и проверка данных нового региона:

    Из тела запроса данные привязываются к структуре NewRegion. Если данные некорректны или не соответствуют ожидаемому формату, возвращается ошибка 400 (Bad Request).
    Проводится валидация данных. Если данные не проходят валидацию, возвращается ошибка 400 с сообщением о невалидных данных.
    Добавление нового региона:

    Определяется последний идентификатор в коллекции регионов, к которому добавляется единица, чтобы создать уникальный ID для новой записи.
    Формируется объект Region с новым ID и данными из запроса.
    Выполняется попытка добавить новый регион в базу данных. При возникновении ошибок, например, если регион с такими же широтой и долготой уже существует, отправляется соответствующая ошибка (409 Conflict или 500 Internal Server Error).
    Отправка ответа:

    При успешном добавлении нового региона отправляется ответ с кодом 201 (Created) и сообщением о создании региона.
    Функция
    AddRegion
    :
    Добавление нового региона в MongoDB:
    Функция получает доступ к коллекции регионов в MongoDB.
    Перед добавлением нового региона проверяется, не существует ли уже регион с такими же широтой и долготой. Если такой регион найден, возвращается ошибка, указывающая на существование региона с такими координатами.
    Если проверка прошла успешно, новый регион добавляется в базу данных. В случае ошибок при добавлении, они обрабатываются и возвращаются.
- PUT
    Этапы функции
    PutRegionByID
    :
    Аутентификация пользователя:

    Функция начинает с проверки идентификатора пользователя, извлеченного из cookie. Если происходит ошибка, функция возвращает статус 401 (Unauthorized), указывая на проблемы с аутентификацией.
    Проверка существования аккаунта пользователя:

    Далее, функция делает запрос к базе данных для проверки существования пользователя по полученному идентификатору. Если аккаунт не найден, возвращается ошибка с кодом 401.
    Получение идентификатора региона:

    Идентификатор региона извлекается из параметров запроса. При ошибке извлечения возвращается статус 400 (Bad Request).
    Привязка и проверка данных:

    Данные из тела запроса привязываются к структуре NewRegion. Если привязка не удаётся или данные не валидны, возвращается ошибка 400.
    Обновление данных региона:

    После успешной валидации данных выполняется запрос на обновление информации о регионе в базе данных. Если обновление вызывает ошибку, например, из-за существования другого региона с такими же широтой и долготой, возвращается ошибка 409 (Conflict). В противном случае, если регион не найден, возвращается ошибка 404 (Not Found).
    Возврат обновленной информации:

    После успешного обновления, функция извлекает обновленную информацию о регионе и отправляет её клиенту с кодом 200 (OK).
    Функция
    PutRegion
    :
    Обновление записи в MongoDB:
    Получается доступ к коллекции Regions через функцию getCollection.
    Проверяется существование региона с указанным идентификатором. Если регион не найден, возвращается ошибка.
    Дополнительно проверяется уникальность широты и долготы. Если найден регион с такими же координатами, но с другим идентификатором, возвращается ошибка о существовании такого региона.
    Если все проверки пройдены успешно, информация о регионе обновляется в базе данных.
- DELETE
    Этапы функции
    DeleteRegionByID
    :
    Аутентификация пользователя:

    Сначала функция пытается получить идентификатор пользователя из cookie. Если это не удаётся, функция отправляет ответ с кодом 401 (Unauthorized), указывая на ошибку аутентификации.
    Проверка существования аккаунта пользователя:

    Далее, функция проверяет, существует ли аккаунт пользователя в базе данных. Если аккаунт не найден, отправляется ответ с кодом 401.
    Получение идентификатора региона:

    Из параметров запроса извлекается идентификатор региона. При ошибке извлечения отправляется ответ с кодом 400 (Bad Request).
    Проверка наличия зависимостей и удаление региона:

    Функция делает запрос к базе данных для удаления региона. Если регион не найден, отправляется ответ с кодом 404 (Not Found). Если регион является родительским для других регионов, отправляется ответ с кодом 400, сообщающий о наличии зависимых регионов.
    Успешное удаление:

    Если удаление прошло успешно и не было зависимостей, функция отправляет ответ с кодом 200 (OK), подтверждая успешное удаление.
    Функция
    DeleteRegionById
    :
    Эта функция отвечает за непосредственное взаимодействие с базой данных MongoDB для удаления региона:

    Получение доступа к коллекции регионов:

    Функция получает доступ к коллекции Regions через функцию getCollection. При ошибке доступа возвращается соответствующая ошибка.
    Поиск региона и проверка на зависимости:

    Сначала выполняется поиск региона по его идентификатору. Если регион не найден, возвращается ошибка, указывающая на его отсутствие.
    Затем проверяется, не является ли регион родительским для других регионов. Для этого выполняется поиск регионов, указывающих на текущий регион как на родительский. Если такие регионы найдены, возвращается ошибка, сообщающая о наличии зависимостей.
    Удаление региона:

    Если регион найден и у него нет зависимостей, он удаляется из базы данных. Информация о количестве удаленных документов регистрируется в журнале.

accountAPI.go
- POST/registration
    Этапы функции
    Registration
    :
    Проверка наличия аутентификации:

    Сначала функция проверяет, есть ли у пользователя уже установленный идентификатор сессии в cookie. Если такой идентификатор найден, это означает, что пользователь уже зарегистрирован, и функция возвращает статус 403 (Forbidden).
    Привязка данных из запроса:

    Далее, функция пытается привязать JSON из тела запроса к структуре AccountRegistration. Если данные неверны или не полны, возвращается ошибка 400 (Bad Request).
    Проверка валидности данных:

    Проводится проверка валидности данных, таких как имя, фамилия, email и пароль. Если данные не проходят валидацию, возвращается ошибка 400.
    Генерация идентификатора для нового аккаунта:

    Определяется последний идентификатор в коллекции аккаунтов, к которому добавляется единица, чтобы создать уникальный ID для новой записи.
    Добавление нового аккаунта:

    Создается объект Account с новым ID и данными из запроса. Попытка добавить новый аккаунт в базу данных. Если email уже существует, возвращается ошибка 409 (Conflict). В случае других ошибок возвращается ошибка 500 (Internal Server Error).
    Отправка ответа:

    При успешном добавлении нового аккаунта, функция извлекает обновленную информацию об аккаунте и отправляет её клиенту с кодом 201 (Created), подтверждая успешную регистрацию.
    Вспомогательные функции:
    isValidAccountRegister:

    Эта функция проверяет корректность данных регистрации, таких как наличие и форматирование имени, фамилии, email и пароля.
    isValidEmail:

    Функция для проверки корректности формата email с использованием регулярного выражения.
    AddAccount:

    Функция, обеспечивающая добавление нового аккаунта в коллекцию аккаунтов MongoDB. Проверяет уникальность email и обрабатывает ошибки, связанные с добавлением данных.
-POST/login
    Этапы функции
    Registration
    :
    Проверка наличия аутентификации:

    Сначала функция проверяет, есть ли у пользователя уже установленный идентификатор сессии в cookie. Если такой идентификатор найден, это означает, что пользователь уже зарегистрирован, и функция возвращает статус 403 (Forbidden).
    Привязка данных из запроса:

    Далее, функция пытается привязать JSON из тела запроса к структуре AccountRegistration. Если данные неверны или не полны, возвращается ошибка 400 (Bad Request).
    Проверка валидности данных:

    Проводится проверка валидности данных, таких как имя, фамилия, email и пароль. Если данные не проходят валидацию, возвращается ошибка 400.
    Генерация идентификатора для нового аккаунта:

    Определяется последний идентификатор в коллекции аккаунтов, к которому добавляется единица, чтобы создать уникальный ID для новой записи.
    Добавление нового аккаунта:

    Создается объект Account с новым ID и данными из запроса. Попытка добавить новый аккаунт в базу данных. Если email уже существует, возвращается ошибка 409 (Conflict). В случае других ошибок возвращается ошибка 500 (Internal Server Error).
    Отправка ответа:

    При успешном добавлении нового аккаунта, функция извлекает обновленную информацию об аккаунте и отправляет её клиенту с кодом 201 (Created), подтверждая успешную регистрацию.
    Вспомогательные функции:
    isValidAccountRegister:

    Эта функция проверяет корректность данных регистрации, таких как наличие и форматирование имени, фамилии, email и пароля.
    isValidEmail:

    Функция для проверки корректности формата email с использованием регулярного выражения.
    AddAccount:

    Функция, обеспечивающая добавление нового аккаунта в коллекцию аккаунтов MongoDB. Проверяет уникальность email и обрабатывает ошибки, связанные с добавлением данных.
- GET
    Этапы функции
    GetAccountByID
    :
    Аутентификация пользователя:

    Сначала функция пытается получить идентификатор пользователя из cookie. Если процесс извлечения или парсинга не удаётся, функция возвращает ответ с кодом 401 (Unauthorized), указывая на ошибку аутентификации.
    Получение данных аккаунта для аутентификации:

    Затем функция делает запрос к базе данных для получения данных аккаунта, используя идентификатор, полученный из cookie. Если аккаунт не найден, возвращается ответ с кодом 401, сообщающий, что аккаунт не существует.
    Валидация идентификатора запрашиваемого аккаунта:

    Из параметров запроса извлекается идентификатор запрашиваемого аккаунта (accountId). При ошибке извлечения отправляется ответ с кодом 400 (Bad Request).
    Запрос к базе данных для получения запрашиваемого аккаунта:

    Функция делает запрос к базе данных для получения данных аккаунта по идентификатору, указанному в параметрах запроса. Если аккаунт не найден, возвращается ответ с кодом 404 (Not Found).
    Отправка данных аккаунта:

    Если данные аккаунта успешно получены, они отправляются клиенту с кодом 200 (OK) в формате JSON.
    Функция
    GetAccountByID
     для работы с базой данных MongoDB:
    Получение доступа к коллекции аккаунтов:

    Функция getCollection используется для получения доступа к коллекции CollectionAccount, где хранятся данные об аккаунтах.
    Поиск аккаунта в базе данных:

    С помощью метода FindOne выполняется запрос к базе данных с фильтром по идентификатору (_id). Если соответствующий аккаунт найден, он декодируется в структуру Account.
    Формирование и возврат результата:

    Из декодированных данных аккаунта формируется объект AccountInfo, который содержит основную информацию о пользователе, такую как имя, фамилия, email и идентификатор. Эти данные возвращаются вызывающей стороне.
-PUT
    Этапы функции
    PutAccountByID
    :
    Аутентификация пользователя:

    Сначала проверяется наличие идентификатора пользователя в cookie. Если возникает ошибка, отправляется ответ 401 (Unauthorized), сообщающий о проблемах с аутентификацией.
    Проверка существования аккаунта пользователя:

    Делается запрос в базу данных для проверки наличия аккаунта с таким идентификатором. Если аккаунт не найден, отправляется ответ 401, уведомляющий, что аккаунт не существует.
    Получение идентификатора аккаунта для обновления:

    Из параметров запроса извлекается идентификатор аккаунта (accountId). При ошибке извлечения отправляется ответ 400 (Bad Request).
    Проверка прав на обновление аккаунта:

    Проверяется, совпадает ли идентификатор пользователя с идентификатором аккаунта, который нужно обновить. Если не совпадает, отправляется ответ 403 (Forbidden), предотвращая обновление чужого аккаунта.
    Привязка и валидация данных аккаунта:

    Данные для обновления привязываются к структуре AccountRegistration. При ошибке привязки отправляется ответ 400.
    Проверяется валидность данных (имя, фамилия, email, пароль). Если данные невалидны, отправляется ответ 400.
    Обновление аккаунта в базе данных:

    Вызывается функция PutAccount, которая обновляет данные в базе данных. При возникновении ошибок (например, если email уже существует у другого аккаунта) отправляется соответствующий ответ 409 или 404, если аккаунт не найден.
    Отправка обновленных данных:

    При успешном обновлении данных аккаунта отправляются обновленные данные с кодом 200 (OK).
    Функция
    PutAccount
    :
    Получение доступа к коллекции аккаунтов:

    Доступ к коллекции аккаунтов получается через функцию getCollection.
    Проверка уникальности email:

    Перед обновлением проверяется, не занят ли новый email другим аккаунтом. Если email уже существует, функция возвращает ошибку.
    Обновление данных:

    Если email уникален, данные аккаунта обновляются в базе данных с использованием операции $set. При возникновении ошибок во время обновления они возвращаются вызывающей стороне.
-DELETE
    Этапы функции
    DeleteAccountByID
    :
    Аутентификация пользователя:

    Сначала функция проверяет, можно ли извлечь идентификатор пользователя из cookie. Если это не удаётся, возвращается ответ с кодом 401 (Unauthorized), указывая на проблемы с аутентификацией.
    Проверка существования аккаунта пользователя:

    Делается запрос к базе данных для проверки существования аккаунта пользователя по полученному идентификатору. Если аккаунт не найден, возвращается ответ с кодом 401, сообщающий, что аккаунт не существует.
    Получение и проверка идентификатора аккаунта для удаления:

    Из параметров запроса извлекается идентификатор аккаунта (accountId). При ошибке извлечения возвращается ответ с кодом 400 (Bad Request).
    Проверка прав на удаление аккаунта:

    Проверяется, совпадает ли идентификатор пользователя с идентификатором аккаунта, который нужно удалить. Если не совпадает, отправляется ответ 403 (Forbidden), предотвращая удаление чужого аккаунта.
    Удаление аккаунта из базы данных:

    Вызывается функция DeleteByIDAndCollection, которая удаляет аккаунт из базы данных. Если аккаунт не найден, возвращается ошибка 404 (Not Found).
    Отправка подтверждения об удалении:

    Если аккаунт успешно удалён, возвращается ответ с кодом 200 (OK), подтверждающий успешное удаление.
    Функция
    DeleteByIDAndCollection
    :
    Получение доступа к коллекции:

    Функция getCollection используется для получения доступа к соответствующей коллекции в MongoDB, в данном случае к коллекции аккаунтов (CollectionAccount).
    Удаление документа:

    Формируется фильтр по идентификатору для поиска и удаления документа. Метод DeleteOne используется для удаления документа из коллекции.
    Если документ успешно удален, функция возвращает nil, подтверждая успешное выполнение операции. Если документ не найден, возвращается ошибка, указывающая на отсутствие документа в базе данных.
-SEARCH
    Этапы функции
    SearchAccount
    :
    Сбор параметров запроса:

    Из параметров запроса извлекаются данные: имя (firstName), фамилия (lastName), и email (email). Эти данные используются для формирования запроса к базе данных.
    Валидация параметров пагинации:

    Параметры form и size используются для управления пагинацией результатов. form указывает на номер страницы, а size — на количество записей на странице. Производится проверка этих параметров на корректность. При обнаружении ошибок отправляется соответствующий ответ с кодом 400 (Bad Request).
    Формирование запроса к базе данных:

    На основе полученных параметров создается запрос к базе данных. Используются регулярные выражения для поиска по полям имени, фамилии и email.
    Поиск в базе данных:

    Выполняется поиск по базе данных с учетом заданных фильтров и параметров пагинации. В случае ошибки выполняется возврат сообщения об ошибке.
    Отправка результатов:

    Полученные результаты возвращаются клиенту в формате JSON с кодом 200 (OK).
    Функция
    GetSearchAccount
    :
    Эта функция выполняет непосредственный запрос к базе данных MongoDB для поиска учетных записей:

    Получение доступа к коллекции:

    Используется функция getCollection для получения доступа к коллекции учетных записей.
    Формирование фильтров поиска:

    Создаются фильтры на основе регулярных выражений для имени, фамилии и email. Эти фильтры позволяют искать записи, соответствующие заданным критериям.
    Настройка параметров поиска:

    Устанавливаются параметры поиска (skip и limit), которые контролируют пагинацию результатов.
    Выполнение запроса:

    Выполняется запрос к базе данных. В случае ошибки или если записи не найдены, возвращается соответствующая ошибка.
    Возврат результатов:

    Результаты, если они найдены, возвращаются в виде списка структур AccountInfo, содержащих основную информацию о найденных аккаунтах.